Network Working Group D. Levi 
Request for Comments: 4318 Nortel Networks 
Category: Standards Track D. Harrington 
Effective Software 

December 2005 


Definitions of Managed Objects for Bridges 
with Rapid Spanning Tree Protocol 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 
Abstract 


This memo defines an SMIv2 MIB module for managing the Rapid Spanning 
Tree capability defined by the IEEE P802.1t and P802.1lw amendments to 
IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) 
segments. The objects in this MIB are defined to apply both to 
transparent bridging and to bridges connected by subnetworks other 
than LAN segments. 
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Le 


The Internet-Standard Management Framework 


For a detailed overview of the documents that describe the current 
Internet-Standard Management Framework, please refer to section 7 of 
RFC 3410 [RFC3410]. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. MIB objects are generally 
accessed through the Simple Network Management Protocol (SNMP). 
Objects in the MIB are defined using the mechanisms defined in the 
Structure of Management Information (SMI). This memo specifies a MIB 
module that is compliant to the SMIv2, which is described in STD 58, 
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 
[RFC2580]. 


Overview 


This memo defines an SMIv2 MIB module for managing the Rapid Spanning 
Tree (RSTP) capability defined by the IEEE P802.1t [802.1t] and 
P802.1w [802.1lw] amendments to IEEE Std 802.1D-1998 [802.1D-1998] for 
bridging between Local Area Network (LAN) segments. The objects in 
this MIB are defined to apply both to transparent bridging and to 
bridges connected by subnetworks other than LAN segments. 


Relationship to IEEE 802.1t and 802.1w Amendments 
This document defines managed objects for the Rapid Spanning Tree 


Protocol defined by the IEEE P802.1t and IEEE P802.1lw amendments to 
802.1D-1998. 


RSTP-MIB Name IEEE 802.1 Reference 
dotldstp 
dotldStpVersion (w) 17.16.1 ForceVersion 
dotldStpTxHoldCount (w) 17.16.6 TxHoldCount 
dotldStpExtPortTable 


17.18.10 mcheck 

1353.33 adminEdgePort 

$23.4 operEdgePort 

3 adminPointToPointMAC 
3 operPointToPointMAC 
5.3 Path Cost 


dotidStpPortProtocolMigration 
dotlidsStpPortAdminEdgePort 
dotldStpPortOperEdgePort 
dotldStpPortAdminPointToPoint 
dotldStpPortOperPointToPoint 
dotlidStpPortAdminPathCost 


There are concerns that there may be changes made in the 802.1D-2004 
edition that would lead to non-backward-compatible SMI changes for 
802.1t and 802.1lw managed objects in the MIB modules. The Bridge MIB 
working group decided to ’freeze’ the technical content of the MIB 
modules at a level that is compatible with the 802.1t and 802.1w 
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versions, and leave to the IEEE 802.1 working group any updates 
beyond this. 


For informational purposes only, these are the references for the 
above objects in 802.1D-2004 [802.1D-2004]. 


RSTP-MIB Name IEEE 802.1D-2004 Reference 
dotldstp 
dotldStpVersion 17.13.4 ForceVersion 
dotldStpTxHoldCount 17.13.12 TxHoldCount 
dotldStpExtPortTable 
dotldStpPortProtocolMigration 17.19.13 mcheck 
dotldStpPortAdminEdgePort 17.13.1 adminEdgePort 
dotldStpPortOperEdgePort 17.19.17 operEdgePort 
dotldStpPortAdminPointToPoint 6.4.3 adminPointToPointMAC 
dotldStpPortOperPointToPoint 6.4.3 operPointToPointMAC 
dot1idStpPortAdminPathCost 17.13.11 Path Cost 


4. Relation to the BRIDGE-MIB 


The objects in the RSTP-MIB supplement those defined in the Bridge 
MIB [RFC4188]. 


The Original BRIDGE-MIB [RFC1493] has been updated in an SMIv2- 
compliant version [RFC4188]. Conformance statements have been added 
and some description and reference clauses have been updated. The 
interpretations of some objects were changed to accommodate IEEE 
802.1t and 802.1w amendments. 


The object dotldStpPortPathCost32 was added to support IEEE 802.1t, 
and the permissible values of dotldStpPriority and 
dotidStpPortPriority have been clarified for bridges supporting IEEE 
802.1t or IEEE 802.1w. The interpretation of 
dotldStpTimeSinceTopologyChange has been clarified for bridges 
supporting the RSTP. 
See the updated BRIDGE-MIB [RFC4188] for details. 

5. Definitions for RSTP-MIB 


RSTP-MIB DEFINITIONS ::= BEGIN 


IMPORTS 


Levi & Harrington Standards Track [Page 3] 


RFC 4318 RSTP MIB December 2005 


MODULE-IDENTITY, OBJECT-TYPE, Integer32, mib-2 
FROM SNMPv2-SMI 

TruthValue 

FROM SNMPv2-TC 

MODULE-COMPLIANCE, OBJECT-GROUP 

FROM SNMPv2-CONF 

dotidStp, dotlidStpPortEntry 

FROM BRIDGE-MIB; 


rstpMIB MODULE-IDENTITY 

LAST-UPDATED "2005120700002" 

ORGANIZATION "IETF Bridge MIB Working Group" 

CONTACT-INFO 
"Email: Bridge-mib@ietf.org" 

DESCRIPTION 
"The Bridge MIB Extension module for managing devices 
that support the Rapid Spanning Tree Protocol defined 
by IEEE 802.1w. 


Copyright (C) The Internet Society (2005). This version of 
this MIB module is part of RFC 4318; See the RFC itself for 
full legal notices." 


REVISION "2005120700002" 

DESCRIPTION 
"The initial version of this MIB module as published in 
RFC 4318." 

::= { mib-2 134 } 


rstpNotifications OBJECT IDENTIFIER ::= { rstpMIB O } 
rstpObjects OBJECT IDENTIFIER ::= { rstpMIB 1 } 
rstpConformance OBJECT IDENTIFIER = { rstpMIB 2 } 


dotldStpVersion OBJECT-TYPE 
SYNTAX INTEGER { 
stpCompatible(0), 
rstp (2) 
} 
MAX-ACCESS read-write 
STATUS current 
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DESCRIPTION 
"The version of Spanning Tree Protocol the bridge is 
currently running. The value ’stpCompatible(0)’ 
indicates the Spanning Tree Protocol specified in 
IEEE 802.1D-1998 and '’rstp(2)’ indicates the Rapid 
Spanning Tree Protocol specified in IEEE 802.1w and 
clause 17 of 802.1D-2004. The values are directly from 
the IEEE standard. New values may be defined as future 
versions of the protocol become available. 


The value of this object MUST be retained across 
reinitializations of the management system." 


REFERENCE 
"IEEE 802.1w clause 14.8.1, 17.12, 17.16.1" 
DEFVAL { rstp } 


::= { dotldStp 16 } 


dotldStpTxHoldCount OBJECT-TYPE 


SYNTAX Integer32 (1..10) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"The value used by the Port Transmit state machine to limit 
the maximum transmission rate. 


The value of this object MUST be retained across 
reinitializations of the management system." 


REFERENCE 
"IEEE 802.1w clause 17.16.6" 
DEF VAL { 3 } 


::= { dotldStp 17 } 


-—- { dotldStp 18 } was used to represent dotldStpPathCostDefault 
-- in an earlier version of this MIB. It has since been 
-- obsoleted, and should not be used. 


dotldStpExtPortTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotidStpExtPortEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"A table that contains port-specific Rapid Spanning Tree 
information." 

::= { dotldStp 19 } 
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dotldStpExtPortEntry OBJECT-TYPE 


SYNTAX DotldStpExtPortEntry 
MAX-ACCESS not-accessible 
STATUS current 

DESCRIPTION 


"A list of Rapid Spanning Tree information maintained by 
each port." 

AUGMENTS { dotlidStpPortEntry } 

::= { dotldStpExtPortTable 1 } 


DotldStpExtPortEntry ::= 
SEQUENCE { 
dotlidStpPortProtocolMigration 
TruthValue, 
dotlidStpPortAdminEdgePort 
TruthValue, 
dotldStpPortOperEdgePort 
TruthValue, 
dotldStpPortAdminPointToPoint 
INTEGER, 
dotldStpPortOperPointToPoint 
TruthValue, 
dotidStpPortAdminPathCost 
Integer32 
} 


dotlidStpPortProtocolMigration OBJECT-TYPE 


SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"When operating in RSTP (version 2) mode, writing true(1) 
to this object forces this port to transmit RSTP BPDUs. 
Any other operation on this object has no effect and 
it always returns false(2) when read." 

REFERENCE 
"IEEE 802.1w clause 14.8.2.4, 17.18.10, 17.26" 

::= { dotldStpExtPortEntry 1 } 


dotlidStpPortAdminEdgePort OBJECT-TYPE 


SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"The administrative value of the Edge Port parameter. A 
value of true(1) indicates that this port should be 
assumed as an edge-port, and a value of false(2) indicates 
that this port should be assumed as a non-edge-port. 
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Setting this object will also cause the corresponding 
instance of dotldStpPortOperEdgePort to change to the 
same value. Note that even when this object’s value 
is true, the value of the corresponding instance of 
dotldStpPortOperEdgePort can be false if a BPDU has 
been received. 


The value of this object MUST be retained across 
reinitializations of the management system." 


REFERENCE 
"IEEE 802.1t clause 14.8.2, 18.3.3" 
::= { dotldStpExtPortEntry 2 } 


dotldStpPortOperEdgePort OBJECT-TYPE 


SYNTAX TruthValue 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The operational value of the Edge Port parameter. The 
object is initialized to the value of the corresponding 
instance of dotldStpPortAdminEdgePort. When the 
corresponding instance of dotldStpPortAdminEdgePort is 
set, this object will be changed as well. This object 
will also be changed to false on reception of a BPDU." 


REFERENCE 
"IEEE 802.1t clause 14.8.2, 18.3.4" 
:= { dotldStpExtPortEntry 3 } 


dotldStpPortAdminPointToPoint OBJECT-TYPE 
SYNTAX INTEGER { 
forceTrue (0), 
forceFalse (1), 
auto (2) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"The administrative point-to-point status of the LAN segment 
attached to this port, using the enumeration values of the 
IEEE 802.1w clause. A value of forceTrue(0) indicates 
that this port should always be treated as if it is 
connected to a point-to-point link. A value of 
forceFalse(1) indicates that this port should be treated as 
having a shared media connection. A value of auto(2) 
indicates that this port is considered to have a 
point-to-point link if it is an Aggregator and all of its 
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members are aggregatable, or if the MAC entity 

is configured for full duplex operation, either through 
auto-negotiation or by management means. Manipulating this 
object changes the underlying adminPortToPortMAC. 


The value of this object MUST be retained across 
reinitializations of the management system." 


REFERENCE 
"IEEE 802.1w clause 6.4.3, 6.5, 14.8.2" 
::= { dotldStpExtPortEntry 4 } 


dotldStpPortOperPointToPoint OBJECT-TYPE 


SYNTAX TruthValue 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The operational point-to-point status of the LAN segment 
attached to this port. It indicates whether a port is 
considered to have a point-to-point connection. 

If adminPointToPointMAC is set to auto(2), then the value 
of operPointToPointMAC is determined in accordance with the 
specific procedures defined for the MAC entity concerned, 
as defined in IEEE 802.1w, clause 6.5. The value is 
determined dynamically; that is, it is re-evaluated whenever 
the value of adminPointToPointMAC changes, and whenever 
the specific procedures defined for the MAC entity evaluate 
a change in its point-to-point status." 

REFERENCE 
"IEEE 802.1w clause 6.4.3, 6.5, 14.8.2" 

::= { dotldStpExtPortEntry 5 } 


dotldStpPortAdminPathCost OBJECT-TYPE 


SYNTAX Integer32 (0..200000000) 
MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 


"The administratively assigned value for the contribution 
of this port to the path cost of paths toward the spanning 
tree root. 


Writing a value of ’0’ assigns the automatically calculated 
default Path Cost value to the port. If the default Path 
Cost is being used, this object returns ’0’ when read. 


This complements the object dotldStpPortPathCost or 


dotlidStpPortPathCost32, which returns the operational value 
of the path cost. 
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The value of this object MUST be retained across 
reinitializations of the management system." 
REFERENCE 
"IEEE 802.1D-1998: Section 8.5.5.3" 
::= { dotldStpExtPortEntry 6 } 


rstpGroups OBJECT IDENTIFIER ::= { rstpConformance 1 } 


rstpCompliances OBJECT IDENTIFIER ::= { rstpConformance 2 } 


rstpBridgeGroup OBJECT-GROUP 
OBJECTS { 
dotldStpVersion, 
dotldStpTxHoldCount 
} 
STATUS current 
DESCRIPTION 
"Rapid Spanning Tree information for the bridge." 
::= { rstpGroups 1 } 


rstpPortGroup OBJECT-GROUP 

OBJECTS { 
dotlidStpPortProtocolMigration, 
dotidStpPortAdminEdgePort, 
dotldStpPortOperEdgePort, 
dotldStpPortAdminPointToPoint, 
dotldStpPortOperPointToPoint, 
dotldStpPortAdminPathCost 

} 

STATUS current 

DESCRIPTION 
"Rapid Spanning Tree information for individual ports." 

::= { rstpGroups 2 } 


rstpCompliance MODULE-COMPLIANCE 
STATUS current 
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DESCRIPTION 
"The compliance statement for device support of Rapid 
Spanning Tree Protocol (RSTP) bridging services." 


MODULE 
MANDATORY-GROUPS { 
rstpBridgeGroup, 
rstpPortGroup 


} 


::= { rstpCompliances 1 } 

END 
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7. IANA Considerations 


The IANA has assigned the following OID: 


Descriptor OBJECT IDENTIFIER value 
rstpMIB { mib-2 134 } 
8. Security Considerations 


There are a number of management objects defined in this MIB module 
with a MAX-ACCESS clause of read-write and/or read-create. Such 
objects may be considered sensitive or vulnerable in some network 
environments. The support for SET operations in a non-secure 
environment without proper protection can have a negative effect on 
network operations. These are the tables and objects and their 
sensitivity/vulnerability: 


Writable objects that could be misused to cause network delays and 
spanning tree instabilities include dotldStpVersion, 
dotldStpTxHoldCount, dotldStpPortProtocolMigration, 
dotldStpPortAdminEdgePort, and dotldStpPortAdminPathCost. 


Levi & Harrington Standards Track [Page 10] 


RFC 4318 RSTP MIB December 2005 


Some of the readable objects in this MIB module (i.e., objects with a 
MAX-ACCESS other than not-accessible) may be considered sensitive or 
vulnerable in some network environments. It is thus important to 
control even GET and/or NOTIFY access to these objects and possibly 
to even encrypt the values of these objects when sending them over 
the network via SNMP. These are the tables and objects and their 
sensitivity/vulnerability: 


dotlidStpVersion could be read by an attacker to identify environments 
containing applications or protocols that are potentially sensitive 
to RSTP mode. 


dotldStpPortAdminPointToPoint could be used to mislead an access 
control protocol, such as 802.1x, to believe that only one other 
system is attached to a LAN segment and to enable network access 
based on that assumption. This situation could permit potential 
man-in-the-middle attacks. 


SNMP versions prior to SNMPv3 did not include adequate security. 

Even if the network itself is secure (for example by using IPsec), 
even then, there is no control as to who on the secure network is 
allowed to access and GET/SET (read/change/create/delete) the objects 
in this MIB module. 


It is RECOMMENDED that implementers consider the security features as 
provided by the SNMPv3 framework (see [RFC3410], section 8), 
including full support for the SNMPv3 cryptographic mechanisms (for 
authentication and privacy). 


Further, deployment of SNMP versions prior to SNMPv3 is NOT 
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 
enable cryptographic security. It is then a customer/operator 
responsibility to ensure that the SNMP entity giving access to an 
instance of this MIB module is properly configured to give access to 
the objects only to those principals (users) that have legitimate 
rights to indeed GET or SET (change/create/delete) them. 
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retain all their rights. 
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might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 
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The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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